1. Field of the Invention
The present invention relates generally to networks, and more particularly to a way to assign flexible prefixes to Switches in Fibre Channel Fabrics while using the currently defined FC_ID address space. This allows end devices in different Fibre Channel Fabrics to communicate with one another, without requiring modifications to existing end devices, or the need to perform Network Address Translation between Fabrics.
2. Description of the Related Art
With the increasing popularity of Internet commerce and network centric computing, businesses and other organizations are becoming more and more reliant on information. To handle all of this data, storage area networks or SANs have become very popular. A SAN typically includes a number of storage devices, a plurality of Hosts, and a number of Switches arranged in a Switching Fabric that connects the storage devices and the Hosts.
Most SANs rely on the Fibre Channel protocol for communication within the Fabric. For a detailed explanation of the Fibre Channel protocol and Fibre Channel Switching Fabrics and Services, see the Fibre Channel Framing and Signaling Standard, Rev 1.90, International Committee for Information Technology Standards (INCITS), Apr. 9, 2003, and the Fibre Channel Switch Fabric—2, Rev. 5.4, INCITS, Jun. 26, 2001, and the Fibre Channel Generic Services—3, Rev. 7.01, INCITS, Nov. 28, 2000, all incorporated by reference herein for all purposes.
In a Fabric, each Host and storage device is identified by a three byte-wide Fibre Channel address, also called FC_ID. Today the address is statically subdivided in three fields denoted Domain_ID, Area_ID, and Port_ID, each one byte long respectively. Within a Fabric, each Switch is assigned a Domain_ID. The end devices attached to a particular Switch are assigned a FC_ID having the Domain_ID of that Switch. The Switch manages the allocation of the Area_ID and Port_ID fields for each end device to guarantee the uniqueness of the assigned addresses in that Domain_ID. For example, if a Switch is assigned a Domain_ID number five and the Switch subdivides its address space in two areas each having three connected end devices, then a possible Fibre Channel address FC_ID allocation is: 5:1:1, 5:1:2, 5:1:3, 5:2:1, 5:2:2, and 5:2:3 respectively.
Fibre Channel frames are used for communication between Hosts and storage devices within a Fabric. A Fibre Channel frame header carries the source and destination Fibre Channel addresses. When a Host wishes to access a storage device, the FC_IDs of the Host and the storage device are inserted into the source and destination fields of the header respectively. The Switches within the Fabric then route the frame to the target end device using the destination FC_ID. The target end device generates a response frame that includes its own FC_ID in the source field and the FC_ID of the Host in the destination field. The frame is then routed across the Fabric in a similar manner as that described above.
The information infrastructure within a large enterprise typically has a number of independent Fabrics, each dedicated to a different organization or application within the enterprise. For example, a large corporation may have Fabrics for the corporate department, sales organization, engineering group, etc. Each Fabric is separate and distinct. The Hosts of one Fabric cannot access or use a resource in another Fabric. The aforementioned arrangement has a number of disadvantages. The Hosts in a given Fabric can communicate only with the storage devices in that same Fabric. Typically there is no way that a Host in one Fabric can communicate with a storage device in a second Fabric. This arrangement is not only inefficient, it is expensive. Since storage devices cannot be shared among Fabrics, separate storage devices are required for each Fabric.
On occasion, it is desirable for resources to be shared across Fabrics, while keeping the Fabrics separate. For example, it may be convenient for a Host in a first Fabric to be able to access a tape drive in a second Fabric. Fibre Channel Fabrics maintain, in operation, several kinds of information, such as the Name Server database, or the Fabric Configuration Server database, or the Zoning database. In addition, Fibre Channel Fabrics notify end devices of any relevant change in the state of the Fabric itself and of other end devices. There are a number of reasons to interconnect different Fabrics without merging them into a single Fabric. The above mentioned databases typically grow more than linearly with the size of a Fabric. The size of the databases is therefore a limiting factor in the size of a given Fabric. Also the notification mechanism does not scale to big Fabrics. Interconnecting separate Fabrics allows confining the above mentioned databases and notifications inside each Fabric, to keep them manageable, while inter-Fabric protocols may allow communication between selected end devices across multiple Fabrics. A number of solutions to enable resource sharing have been proposed.
One proposed solution involves the virtualization of the end devices so that there are “local instances” of each end device in each Fabric. See for example US Patent Publication 2003/0012204. With this approach, a gateway is needed to couple two (or more) Fabrics. The gateway is required to perform FC_ID translations (i.e., Network Address translations or NATs) for the source and destination end devices. Several problems are associated with NAT translations. If the gateway that performs the translations fails, an alternative or fail-over path across a second gateway needs to be created. The second gateway must have the same state information of the failed gateway. This requires a great deal of management by the Fabric administrator. In addition, with certain FC frames, both the source and/or destination FC_IDs may be carried in the frame payload. A mechanism that identifies and translates these FC_IDs must therefore be provided. This solution also does not work if encryption or a proprietary protocol is used between the source and destination end devices because there is no way for the translating gateway to process the proprietary payloads or decrypt the frames to identify the source and destination FC_IDs possibly carried inside the payload. While in certain cases this approach may be enough, in the general case, the management overhead of this proposal is highly burdensome and is very not practical.
Another proposed solution is the extension of the address space beyond the current three bytes to include the addition of a source Fabric_ID field and a destination Fabric_ID. During communication, the source and destination Fabric_IDs are specified in the FC frame header along with the source and destination FC_IDs. While this proposal eliminates the NAT translation, it is also impractical because it is not backward compatible with existing networking infrastructure. Existing Switches and end devices do not recognize Fabric_IDs. To implement this solution, an entirely new networking infrastructure that supports the use of Fabric_IDs would be needed. In particular, not only the Switches, but also all the end devices need to be replaced. This solution is therefore extremely impractical.
A way to assign flexible prefixes to Switches in Fibre Channel Fabrics while using the currently defined FC_ID address space is therefore desired, in order to allow end devices in different Fibre Channel Fabrics to communicate with one another, without requiring modifications to existing end devices, or the need to perform Network Address Translation between Fabrics.